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(57) Abstract: The invention concerns a 
method for storing information objects or 
objects (5) in a relational database (2) stored 
in a server computer (1), the relational database 
(2) consisting of tables, each formed by a 
table of single data sets having the same data 
structure in a common table, each single data 
being designated by a single identifier in said 
table, an object (6) consisting of one or several 
single data capable of being stored in a table of 
the database (2), and/or one or several objects 
nested in said object. The nesting can be 
produced on any number of levels to produce 
an object (6), a nested object or a single 
data said to be locally in fixed number if it 
appears exactly once in the object immediately 
containing it and said to be locally in variable 
number otherwise. A single data occurring at 
a particular level of said object (6) is said to be 
globally in fixed number if it is locally fixed 
and all the objects containing it are in fixed 
number, a single data occurring at a particular 
level of said object is said to be invariable 
number if it is locally in variable number or if 



c5 



any one of ihc objects containing it is locally in variable number. The data globally in fixed number of an object to be stored (6) 
arc stored in a main data set (31 ) stored in a main table (3) of the database (2). The single data globally in variable number of said 
object to be stored (6) arc stored in one or several auxiliary tables (4, 5, 7) of the database (2). When they exist, the single data 
globally in variable number of said objects (6) are stored in a single auxiliary table (7) of the database. The method create one or 
several sets of auxiliary data sets (71) to store single data globally in variable number in the single auxiliary table (7). 



(57) Abrege : Proccde de stockage d'objets informationnels ou objets (6), dans une base de donnees relationnelle (2) stockee dans 
^ un ordinatcur scrvcur ( 1 ), la base de donnees relationnelle (2) etant constitute de tables, chacune constitute d'un tableau d'ensembles 
de donnees simples qui onl 
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la meme structure de donnees dans une meme table, chaque donnee simple d'une table est designee par un identifiant unique dans 
ladite table, un objet (6) etant constitue d' une ou plusieurs donnees simples pouvant etre stockees dans une table de la base de donnees 
(2), et/ou d'un ou plusieurs objets emboites dans ledit objet. L'embottement peut etre realise sur un nombre quelconque de niveaux 
pour realiserun objet (6), un objet emboite ou une donnee simple etant dit localement en nombre fixe s'il ou elle apparait exactement 
une fois dans T objet le ou la contenant immediatement et etant dit localement en nombre variable dans le cas contraire. Une donnee 
simple apparaissant a un niveau quelconque dudit objet (6) est dite globalement en nombre fixe si elle est localement en nombre fixe 
et si tous les objets la contenant sont localement en nombre fixe, une donnee simple apparaissant a un niveau quelconque dudit objet 
(6) est dite globalement en nombre variable si elle est localement en nombre variable ou si 1'un quelconque des objets la contenant est 
localement en nombre variable. Les donnees globalement en nombre fixe d'un objet a stocker (6) sont stockees dans un ensemble de 
donnees principal (31) stocke dans une table principale (3) de la base de donnees (2). Les donnees simples globalement en nombre 
variable dudit objet a stocker (6) sont stockees dans une ou plusieurs tables annexes (4, 5, 7) de la base de donnees (2). Lorsqu'elles 
existent, les donnees simples globalement en nombre variable desdits objets (6) sont stockees dans une unique table annexe (7) de la 
base de donnees, le procede cree un ou plusieurs ensembles de donnees annexes (71) pour stocker les donnees simples globalement 
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PROCEDE DE STOCKAGE D'OBJETS INFORMATIONNELS AU FORMAT 
XML DANS UNE BASE DE DONNEES RELATIONNELLE 

La presente invention a pour objet les precedes de stockage d'objets 
informationnels, ou objets, dans un systeme informatique, et plus particulierement, 
5 un precede de stockage, dans une base de donnees relationnelle traditionnelle, 
d'objets au format extended Markup Language, ou XML, du consortium Internet 
World Wide Web, ou W3C. 

Les systemes de stockage de donnees sont bien connus dans les techniques 
de traitement de l'information, et de plus en plus frequemment, ils mettent en oeuvre 
1 0 des systemes de gestion de bases de donnees relationnelles. 

Ces systemes sont bien adaptes au stockage de donnees comportant des 
parties en nombre fixe et des parties en nombre variable, les parties en nombre fixe 
etant stockees dans une table principale et les parties en nombre variable etant 
chacune stockees dans une table annexe de la base de donnees. En general, ces 
1 5 systemes permettent en outre de cascader les donnees en nombre variable, c'est-a-dire 
que chaque ensemble ou enregistrement de donnees en nombre variable peut etre a 
) son tour associe a d'autres donnees en nombre variable. En outre, ces systemes de 

gestion de base de donnees offrent habituellement des possibility ^interrogation 
sophistiquee, et de bonnes performances, meme sous forte charge. 
20 En l'absence de systemes efficaces de gestion de bases de donnees orientes 

objets, il est tentant d'utiliser les systemes de gestion de bases de donnees 
relationnelles du commerce pour la gestion et le stockage ou la gestion d'objets. 
Toutefois, ces systemes sont mal adaptes a la gestion d'objets. En effet, dans ces 
systemes traditionnels, les donnees sont stockees dans des tables d'ensembles de 
25 donnees ayant une structure fixe, ces ensembles de donnees etant constitues de 
donnees simples. Cela signifie en particulier qu'il n'est pas possible d'imbriquer ou 
d'emboiter des ensembles de donnees a Tinterietir d ! un autre, meme si les ensembles 
de donnees sont en nombre fixe. 

Ce dernier point pose probleme pour la gestion d'objets en ce que 
30 Temboitement d f objets les uns a Tinterieur des autres est le fondement meme de la 
gestion de donnees orientee objets. II est theoriquement possible de resoudre ce 
probleme automatiquement en mettant "a plat" la structure de Tobjet, c'est-a-dire, en 
considerant que tous les elements de sous-objets inclus dans un objet principal sont 
en fait des elements de Tobjet principal. 
3 5 Cela introduit un nouveau probleme en ce que les noms d f elements contenus 

dans des sous-objets distincts dun meme objet peuvent parfaitement etre identiques 
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et que les noms d'elements dans un meme objet doivent necessairement etre distincts, 
pour d'evidentes raisons de non-ambiguJte. Ce nouveau probleme peut a son tour etre 
resolu automatiquement en incluant le nom du sous-objet contenant dans le nouveau 
nom "a plat" d'un element d'un sous-objet. En pratique, cela revient a ajouter les 
5 noms de tous les objets contenants a Telement contenu pour obtenir un nom "a plat" 
non ambigu. 

Malheureusement, cette technique conduit rapidement a des noms "a plat" 
ayant une longueur de nom depassant les limites autorisees par les systemes de 
gestion de bases de donnees, meme pour des elements peu imbriques, du fait que ces 

10 systemes imposent des limites de Tordre de quelques dizaines de caracteres sur la 
longueur des noms des donnees simples stockees dans une table. Cette nouvelle 
difficulty est habituellement resolue en tronquant le nom "a plat" obtenu a la 
longueur permise par le systeme. Toutefois, ce precede conduit usuellement a des 
noms "a plat" dupliques. 

15 La resolution definitive de ce probleme implique habituellement une 

intervention manuelle d'un operateur humain, qui definit lui-meme les noms a utiliser 
dans le systeme de gestion de base de donnees, pour chaque element d f objet 
imbrique. De fa?on evidente, cette intervention manuelle est sujette a erreur et elle 
est couteuse en temps humain. 

20 Par ailleurs, la technique consistant a utiliser une table annexe pour chaque 

partie en nombre variable d'un objet conduit rapidement a des performances 
deplorables lorsqu ! un objet comporte de nombreuses parties en nombre variable, 
comme c'est souvent le cas en pratique. En effet, chaque acces a un objet stocke dans 
la base de donnees requerra un acces a la base de donnees pour la table principale 

25 plus autant d'acces a la base de donnees qu'il y a de tables annexes, c f est-a-dire, de 
parties d'objets en nombre variable dans un objet. Si Tobjet comporte, comme il est 
frequent, cinq ou dix parties en nombre variable, le nombre d ! acces a la base de 
donnees sera multiplie par cinq ou dix par rapport a un objet n'ayant pas de parties 
variables, ce se traduit par une degradation des performances dans un meme rapport. 

30 Cette degradation peut devenir critique dans les systemes de stockage de 

donnees tres sollicites, tels que les serveurs Internet, car il n ! est pas toujours possible 
de dupliquer les serveurs pour repartir la charge, en particulier lorsque les donnees 
presentes sur un serveur peuvent etre modifiees. En outi'e, cela augmente dans les 
memes proportions la fragilite du systeme de stockage vis-a-vis d ! une panne de 

35 courant ou de tout autre probleme systeme entrainant un arret inopine du systeme 
informatique hebergeant la base de donnees. 
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II existe done un besoin pour un procede qui permette d'adapter les systemes 
de gestion de base de donnees relationnelles existants aux specificites du stockage 
d'objets, en gerant automatiquement les limites imposees sur la longueur des noms 
des donnees simples stockees dans les tables et limitant le nombre de tables annexes 
5 utilisees pour conserver de bonnes performances au systeme de stockage d f objets 
dans son ensemble. 

La presente invention a done pour objet de proposer un procede et un 
systeme qui permettent de limiter a une table principale et une table annexe le 
nombre de tables necessaire pour stocker les donnees simples en nombre fixe et 
1 0 variable d'une collection d f objets informatiques presents dans un systeme de stockage 
de donnees. 

La presente invention propose done un procede de stockage d'objets 
informationnels ou objets dans une base de donnees relationnelle stockee dans un 
ordinateur serveur, ladite base de donnees relationnelle etant constitute de tables, 

15 chaque table etant constitute d'un tableau d'ensembles de donnees simples, lesdits 
ensembles ayant la meme structure de donnees dans une meme table, chaque donnte 
simple d'une table etant designee par un identifiant unique dans ladite table, un objet 
etant constitue d'une ou plusieurs donnees simples pouvant etre stockees dans une^ 
table de ladite base de donnees, et/ou d'un ou plusieurs objets emboites dans ledit 

20 objet, ledit emboitement pouvant etre realise sur un nombre quelconque de niveaux 
pour realiser un objet, un objet emboite ou une donnee simple etant dit localement en 
nombre fixe s'il ou elle apparait exactement vine fois dans l'objet le ou la contenant 
immediatement et etant dit localement en nombre variable dans le cas contraire, une 
donnee simple apparaissant a un niveau quelconque dudit objet etant dite 

25 globalement en nombre fixe si elle est localement en nombre fixe et si tous les objets 
la contenant sont localement en nombre fixe, une donnee simple apparaissant a un 
niveau quelconque dudit objet etant dite globalement en nombre variable si elle est 
localement en nombre variable ou si Tun quelconque des objets la contenant est 
localement en nombre variable, lesdites donnees globalement en nombre fixe d ! un 

30 objet a stocker etant stockees dans un ensemble de donnees principal stocke dans une 
table principale de ladite base de donnees, lesdites donnees simples globalement en 
nombre variable dudit objet a stocker etant stockees dans une ou plusieurs tables 
annexes de ladite base de donnees, qui a pour caracteristique le fait que, lorsqu ! elles 
existent, les donnees simples globalement en nombre variable desdits objets sont 

35 stockees dans vine unique table annexe de ladite base de donnees, le procede creant 
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un ou plusieurs ensembles de donnees annexes pour stocker lesdites donnees simples 
globalement en nombre variable dans ladite unique table annexe. 

Dans ce precede, chacun desdits un ou plusieurs ensembles annexes 
eventuellement stockes dans ladite unique table annexe peut comporter en outre un 
5 ensemble d'indicateurs booleens, chaque indicateur booleen etant associe a une 
donnee particuli&re desdites donnees simples globalement en nombre variable 
stockees dans ledit ensemble annexe, ledit indicateur booleen indiquant si ladite 
donnee simple globalement en nombre variable associee est definie ou non dans ledit 
ensemble annexe. Dans ce cas, certains desdits indicateurs booleens dudit ensemble 

10 d'indicateurs booleens pourront etre communs a plusieurs donnees simples 
globalement en nombre variable lorsque lesdites donnees simples sont localement en 
nombre fixe dans un meme objet les contenant immediatement. 

De preference, ledit ensemble principal associe au dit objet a stocker 
comportera une donnee permettant d'identifier de fa$on unique ledit ensemble 

15 principal dans ladite table principals De plus, ladite donnee unique pourra etre 
unique dans ledit ordinateur serveur, et avantageusement, ladite donnee unique 
stockee dans ledit ensemble principal associe au dit objet a stocker sera en outre 
stockee dans chacun des ensembles annexes associes au dit objet a stocker, pour 
permettre la mise en relation dudit ensemble principal et du ou desdits ensembles 

20 annexes eventuels associes au dit objet a stocker. 

De fa9on avantageuse, ladite donnee unique pourra etre constitute du nom 
logique de l'ordinateur serveur sur ledit reseau, du numero de table de ladite table 
principaie dans ladite base de donnees et du numero d f ensemble de donnees dudit 
ensemble principal dans ladite table principaie, ledit nom logique de l'ordinateur 

25 serveur etant unique sur ledit reseau, ladite base de donnees etant unique sur ledit 
ordinateur serveur, ledit numero de table de ladite table principaie etant unique dans 
ladite base de donnees et ledit numero d'ensemble de donnees dudit ensemble 
principal etant unique dans ladite table principaie. 

Dans le procede, deux objets a stocker pourront etre dits de meme type s'ils 

30 sont constitues de donnees simples et d'objets emboites de meme type, deux objets de 
meme type ayant en commun un meme identifiant et les donnees simples et/ou les 
objets emboites se correspondant a un niveau quelconque desdits objets de meme 
type ayant en commun un meme identifiant, unique dans I'objet les contenant 
immediatement. 

35 Dans ce cas, le procede pourra creer un identifiant global pour tous les 

objets de meme type et pour toutes les donnees simples se correspondant k un niveau 
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quelconque desdits objets de meme type, ledit identifiant global etant ledit identifiant 
commun pour lesdits objets de meme type, et ledit identifiant global etant obtenu, 
pour chacune desdites donnees simples se correspondant, par la concatenation des 
identifiants, dans les objets les contenant immediatement, de tous les objets 
5 contenant ladite donnee simple, et de l'identifiant de ladite donnee simple dans Tobjet 
la contenant immediatement 

En outre, le nombre de caracteres de cet identifiant global pourra etre 
tronque au nombre de caracteres permis par ladite base de donnees pour l'identifiant 
d'une donnee stockee dans une table de ladite base de donnees. Egalement, une 
10 ambiguite pouvant apparaitre du fait de ladite troncature pourra etre resolue en 
effectuant les etapes consistant a : 

- remplacer le dernier caractere alphabetique de l'identifiant global par le 
chiffre zero, ainsi que les eventuels chif&es le suivant ; 

augmenter d'une unite le nombre constitue par l'ensemble des chif&es 
15 apparaissant a la fin dudit identifiant global jusqu'a ce que Tambiguite 

disparaisse ou que les cbiffires a la fin dudit identifiant global soienf 
entierement constitues de chif&es neuf ; 

- repeter les etapes precedentes depuis le debut lorsque les chif&es 
apparaissant a la fin dudit identifiant global sont entierement constitues 

20 de chiffres neuf a Tissue de l'etape precedente. 

Dans le procede de l'invention, les objets stockes dans la base de donnees 
pourront etre re9us ou transmis par Tordinateur serveur via un reseau informatique de 
type Internet. 

De preference, les donnees simples constituant lesdits objets (6) stockes 
25 dans ladite base de donnees seront de type texte, et avantageusement, lesdites 
donnees simples de type texte seront des donnees ecrites en langage XML. De plus, 
. lesdites donnees ecrites en langage XML pourront etre conformes a une description 
de type XML Schema. 

En outre, un ensemble de donnees au format XML pourra etre obtenu par 
30 une traduction automatique de ladite description, ledit ensemble de donnees et un 
ensemble de donnees complementaire etant a leur tour traduits automatiquement en 
langage SQL pour definir et gerer la structure de la base de donnees, et pour controler 
les echanges de donnees avec ladite base de donnees. 

Par ailleurs, dans le procede de Tinvention, une partie des donnees simples 
35 des objets re9us par ledit reseau de type Internet pourra etre supprimee a Taide d'un 



WO 02/03245 



PCT/FR00/01902 



6 

patron, ou modele, d'objet ecrit en langage XML, pour interdire la modification 
desdites donnees simples via ledit reseau. 

Egalement, une partie des donnees simples des objets transmis via ledit 
reseau pourra etre supprimee a l'aide d'un patron d'objet ecrit en langage XML pour 
5 limiter la transmission sur ledit reseau a certaines donnees simples desdits objets. De 
plus, la suppression d ! une partie des donnees simples contenues dans les objets 
permettra en outre d'optimiser les requetes a ladite base de donnees. 

L ! invention propose en outre un systeme de stockage d f objets 
informatioimels ou objets, dans une base de donnees relationnelle stockee par un 
10 ordinateur serveur, qui a pour caracteristique le fait qu f il met en oeuvre le procede 
selon Time quelconques des revendications precedentes. 

Un mode de realisation preferentiel de Tinvention va maintenant etre decrit, 
a titre d f exemple seulement, en se referant aux dessins annexes, dans lesquels : 

- la figure Infest le schema fonctionnel du mode de realisation prefere du 
1 5 procede de stockage d'objets selon la presente invention ; 

- la figure 2 est un schema montant l'utilisation d'une table annexe unique 
pour les ensembles en nombre variable dans le mode de realisation 
prefere du procede de l'invention sur un cas d'exemple ; 

- la figure 3 est un schema montant l'utilisation d f un ensemble de tables 
20 annexes pour les ensembles en nombre variables dans la technique 

anterieure, sur le meme cas d'exemple que celui de la figure 2. 
Pour permettre la comparaison, un exemple de stockage d'objet de la 
technique anterieure sera egalement decrit. Dans les deux cas, on supposera, de fa9on 
non restrictive, que le systeme de gestion de base de donnees relationnelle, ou 
25 SGBDR, utilise est mis en oeuvre a l'aide du langage standard Structured Query 
Language, ou SQL. 

Par ailleurs, pour faciliter la comprehension, on decrira les operations de 
stockage concernant un objet 6 d'exemple, tel qu'une entree dans un annuaire 
comportant les informations suivantes : 
30 Entree annuaire : 

Nom, sur 40 caracteres : OTOOBE 
Telephone, sur 15 caracteres : +33(0)1 44 34 85 03 
Telecopie, sur 15 caracteres : +33(0)1 44 34 85 01 
Adresse : 

35 Rue, sur 40 caracteres : 3 bis, rue du Docteur-Foucault 

Ville, sur 40 caracteres : 92000 NANTERRE 
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Adresse : 

Rue 3 sur 40 caracteres : 34, bd Haussmann 
Vffle, sur 40 caracteres : 75009 PARIS 
Contact, sur 40 caracteres : M. Laurent QUEREL 
5 Contact, sur 40 caracteres : M. Jean-Francis QUENTDSf 

Contact, sur 40 caracteres : M. Gilles ANDRE 

Dans cette entree, les donnees "Adresse" et "Contact" sont supposees 

pouvoir figurer en nombre variable dans ledit objet 6 "Entree annuaire", pour prendre 

en compte le fait qu'une entreprise peut comporter plusieurs etablissement et 
10 plusieurs personnes a contacter. Pour la clarte de 1'expose, le nombre des donnees en 

nombre variable a ete limite a deux dans cet exemple, mais ce nombre ne limite en 

rien la portee du precede de la presente invention. 

Les objets infonnationnels, ou objets, dont la structure de donnees n ! est pas 

fixe, permettent de prendre en compte ce type de donnees en nombre variable,.ce qui 
1 5 fait toute la puissance de rapproche objet par rapport a une approche traditionnelle ou 

la structure des donnees est fixe, et dans laquelle il est done necessaire de prevoir a . 

l'avance un nombre maximal d'occurrences pour chaque donnee, au risque d'un cote 

de bloquer de fa9on genante un cas particulier ou un nombre d'occurrences plus . 

important que celui prevu serait necessaire, et d'un autre cote, de gaspiller 
20 inutilement de la place de stockage dans le cas general pour quelques cas particuliers 

peu frequents. 

Malheureusement, les systemes de gestion de base de donnees classiques 
actuels ne permettent pas directement le stockage d'objets, e'est-a-dire de structures 
de donnees permettant l'emboitement de sous-structures de donnees et des 
25 occurrences multiples pour les elements de ces structures, ce qui necessite un 
traitement particulier des donnees de l'objet 6 "Entree annuaire" pour pouvoir le 
stocker dans la base de donnees 2. 

Dans la technique anterieure, ce traitement consiste a separer les donnees en 
nombre fixe "nom", "telephone", "telecopie" et les donnees en nombre variable "rue", 
30 "ville" en stockant les donnees en nombre fixe dans une premiere table principale 3, 
et en stockant les donnees, ou ensembles de donnees, en nombre variable dans autant 
d f autres tables annexes qu ! il existe de donnees, ou d'ensembles de donnees, en 
nombre variable dans Tobjet 6. 

Dans la technique anterieure, l'objet 6 de Texemple precedent est alors 
3 5 stocke sous la forme indique k la figure 3, dans laquelle : 
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- la table 3 est la table.principale stockant les ensembles 3 1 de donnees en 
nombre fixe constitues des donnees simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14 ; 

- la table 4 est une premiere table annexe stockant les ensembles 41 
5 constitues de la donnee simple "cle" 11 et de la donnee en nombre 

variable "adresse", c'est-a-dire, des donnees simples "rue" 15 et "ville" 
16; 

- la table 5 est une seconde table annexe stockant les ensembles de 
donnees constitues de la donnee "cle" 11 et de la donnee en nombre 

10 variable "contact" 17. 

Plus precisement, dans Texemple ci-dessus, la donnee "nom" ayant pour 
valeur "OTOOBE" sera stockee en 12, la donnee "telephone" ayant pour valeur 
"+33(0)1 44 34 85 03" sera stockee en 13, la donnee "telecopie" ayant pour valeur 
"+33(0)1 44 34 85 01" sera stockee en 14, la donnee "rue" du premier sous-objet 
15 "adresse", ayant pour valeur "3bis, rue du Docteur-Foucault", sera stockee en 15 i, la 
donnee "ville" du premier sous-objet "adresse", ayant pour valeur "92000 
NANTERRE", sera stockee en \6 U la donnee "rue" du second sous-objet "adresse", 
ayant pour valeur "34, bd Haussmann", sera stockee en 15 2 , la donnee "ville" du 
second sous-objet "adresse", ayant pour valeur "75009 PARIS", sera stockee en 16 2 , 
20 la premiere donnee "contact", ayant pour valeur "M. Laurent QUEREL", sera stockee 
en 17i ? la seconde donnee "contact", ayant pour valeur "M. Jean-Francis 
QUENTIN", sera stockee en 17 2 et la troisieme donnee "contact", ayant pour valeur 
"M. Gilles ANDRE", sera stockee en 17 3 . 

La donnee "cle" 11 apparaissant dans les tfois tables 3, 4 et 5 est la cle 
25 primaire de ces tables, et son utilisation sera decrite plus loin. 

Pour pouvoir utiliser ces donnees, il faut au prealable definir les tables 3, 4 
. et 5 dans la base de donnees 2, ainsi que les diverses donnees stockees dans ces 
tables 3, 4 et 5. 

Dans la technique anterieure, pour creer la table 3, un operateur devait 
3 0 typiquement indiquer manuellement au SGBDR une instruction SQL du type : 
CREATE TABLE "EntreeAnnuaire_main" ( 
cle INTEGER, 
nom VARCHAR(40), 
telephone VARCHAR(1 5), 
35 telecopie VARCHAR(1 5), 

PRIMARY KEY (cle)) 



WO 02/03245 



PCT/FR00/O1902 



9 

Dans cette instruction, la rubrique "EntreeAnnuaire_main" indique le nom, 
librement choisi par l'operateur sous r6serve d'unicite, de la table principale 3, et une 
rubrique "VARCHAR(n)" indique une chaine de caracteres de longueur variable et 
de longueur maximale n. La donnee "cle" 1 1 est la cle primaire evoquee ci-dessus et 
5 qui sera decrite plus loin, et la rubrique "PRIMARY KEY(cle)" indique precisement 
au systeme que cette donnee "cle" 1 1 est la cle primaire. 

De meme, dans la technique anterieure, pour creer les tables 4 et 5, un 
operateur devait typiquement indiquer manuellement au SGBDR des instructions 
SQL du type : 

10 CREATE TABLE "EntreeAnnuaire_l"( 

cle INTEGER, 
rue VARCHAR(40), 
villeVARCHAR(15), 
PRIMARY KEY (cle)) 

15 et: 

CREATE TABLE "EntreeAnnuaire_2" ( 
cle INTEGER, 
contact VARCHAR(40), 
PRIMARY KEY (cle)) 

20 dans lesquelles les rubriques "Entree Annuaire_l" et " Entree Annuaire_2" sont les . 
noms respectifs, librement choisis, des tables annexes 4 et 5. 

En outre, l'operateur devait definir egalement manuellement les donnees 
indexees, e'est-a-dire les donnees dont le contenu pourra permettre de retrouver une 
entree de l'annuaire, au moyen d'instructions SQL du type : 

25 CREATE INDEX "IndexNom" ON "Entree Annuaire_main" (nom) 

qui indique au SGBDR de faire en sorte qu'une entree d'annuaire puisse etre 
retrouvee par le contenu de la rubrique "nom" de la table principale 3 
"Entree Annuaire_main" . 

De plus, dans le cas d'objets 6 comportant de nombreux niveaux 

30 d'emboitement et de nombreuses donnees en nombre variable comme e'est souvent le 
cas en pratique, le nombre de tables annexes etait eleve, et la numerotation ou la 
denomination des tables annexes etait beaucoup plus complexe que celle presentee 
dans l'exemple precedent. A nouveau, cette numerotation ou cette denomination 
necessitait une intervention manuelle d'un operateur, avec les risques d'erreur 

3 5 inherents a toute operation manuelle. 
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En se referant aux figures 1 et 2, on va maintenant decrire le precede de 
stockage selon le mode de realisation prefere de l'invention, qui est mis en oeuvre par 
divers modules de programmes globalement denommes Collective Operating System 
ou COS dans ce document. 
5 En revenant a l'exemple precedent, le precede de l'invention gere l'ensemble 

31 de donnees simples en nombre fixe "cle" 11, "nom" 12, "telephone" 13, et 
"telecopie" 14 dans la table principale 3 de la meme maniere que dans la technique 
anterieure, c'est-a-dire en utilisant directement les primitives adequates du SGBDR 
utilise. 

10 Par contre, la gestion des donnees simple en nombre variable est effectuee a 

l'aide d'une unique table 7, au lieu des tables 4 et 5. Pour cela, le precede de 
1'invention stocke la premiere occurrence d'une donnee simple en nombre variable 
dans un premier ensemble de donnees 71 j de la table 7, la seconde occurrence d ! une 
donnee simple en nombre variable dans un second ensemble de donnees 71 2 de la 

15 table 7, la troisieme occurrence eventuelle d'une donnee simple en nombre variable 
dans un troisieme ensemble de donnees 71 3 , etc.. On voit alors que la structure de 
donnees de la table 7, c'est-a-dire la structure des ensembles de donnees 71, doit 
necessairement comporter au moins 1'union des donnees simples en nombre variable 
dans un objet 6. 

20 Comme dans la technique anterieure, la donnee "cle" 1 1 apparaissant dans 

les deux tables 3 et 7 est la cle primaire de ces tables, et son utilisation sera decrite 
plus loin. 

En revenant a l'exemple precedent, le precede stocke done la donnee 
premiere occurrence de la donnee simple "rue" de l'objet 6 dans l'emplacement 15! de 

25 l'ensemble 71] de la table 7, il stocke la premiere occurrence de la donnee "ville" 
dans l'emplacement 16i de l'ensemble 71 1 de la table 7, il stocke la seconde 
occurrence de la donnee "rue" dans l'emplacement 15 2 de l'ensemble 71 2 , il stocke la 
seconde occurrence de la donnee "ville" 16 2 dans l'emplacement 16 2 de l'ensemble 
71 2 , il stocke la premiere occurrence de la donnee "contact" 17i dans l'emplacement 

30 17i de l'ensemble 71 1, il stocke la seconde occurrence de la donnee "contact" 17 2 
dans l'emplacement 17 2 de l'ensemble 71 2 , et il stocke la troisieme occurrence de la 
donnee "contact" 17 3 dans l'emplacement 17 3 de l'ensemble 71 3 . 

Toutefois, on voit dans ce qui precede que les emplacements correspondants 
aux donnees simples "rue" et "ville" aux emplacements 15 3 et 16 3 dans l'ensemble de 

35 donnees simples 7l 3 ne sont pas remplis, ce qui est du au fait qu'il n'y a que deux 
ensembles de donnees en nombre variable "rue" et "ville", et qu'il y a trois donnees 
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en nombre variable "contact". Cela pose un probleme en ce sens que si les ensembles 
de donnees simples 71 1, 71 2 , 71 3 etaient stockes en l'etat dans la base de donnees, 
l'information concernant quels emplacements sont remplis et quels emplacements 
sont vides serait longue et difficile a determiner. II serait en effet necessaire de tester 
5 la nullite des colonnes de l'ensemble de ces donnees simples nombre variable pour 
determiner l'absence ou la presence de ces donnees en nombre variable. 

Pour resoudre ce probleme, le procede selon rinvention reservera en outre, 
dans chaque ensemble 71, des emplacements de donnees pour stocker cette 
information de presence ou d'absence pour chaque donnee en nombre variable dans 

10 cet ensemble 71. 

En pratique, dans le cas de donnees simples en nombre fixe, telles que "rue" 
et "ville" associees dans un meme sous-objet contenant tel que "adresse", les donnees 
simples en nombre fixe associees seront toujours presentes ou absentes 
simultanement, ce qui signifie que le procede pourra optimiser le nombre 
15 d'indicateurs en ne stockant qu'un seul indicateur par ensemble de donnees en 
nombre fixe associees. 

Dans ces conditions, lors de la creation de la table 7, le procede ajoute dans 
la structure de donnees de la table 7, c'est-a-dire dans chaque ensemble 71, une 
donnee booleenne pour chaque ensemble de donnees en nombre variable dans l'objet 
20 6. Dans l'exemple decrit, l'ensemble de donnees simples 72 constitue des donnees 
simples booleennes 20 et 21 est ainsi ajoute a chaque ensemble 71, la donnee 
booleenne 20 indiquant la presence, dans l'ensemble 71 considere, de l'ensemble 
constitue des donnees simples "rue" 15 et "ville" 16, et la donnee booleenne 21 
indiquant la presence, dans l'ensemble 71 considere de la donnee "contact" 17. 
25 Ainsi, les informations de presence ou d'absence des donnees ou des 

ensembles de donnees en nombre variable seront conservees lors de l'ecriture d'un 
objet 6, et le procede pourra utiliser ces informations lors des relectures ulterieures, 
pour reconstituer correctement l'objet 6 tel qu'il etait au moment de son 
enregistrement. 

30 On notera qu'avec le procede de rinvention, le nombre d'ensembles de 

donnee presents dans l'unique table annexe est egal au maximum des nombres des 
donnees en nombre variable dans l'objet 6, alors que ce nombre d'ensembles de 
donnees dans les tables annexes est egal a la somme des nombres de donnees en 
nombre variable de l'objet 6 dans la technique anterieure, c'est-a-dire un nombre 

35 toujours plus eleve. 
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Par ailleurs, dans le mode de realisation preferentiel, le procede est utilise 
pour stocker des objets 6 ecrits en langage XML qui sont conformes a une 
description 92 de type XML Schema, ce qui signifie en particulier que cette 
description est elle-meme ecrite dans le langage XML. 

Cette description 92, denommee COSSchema dans le mode de realisation 
preferentiel, decrit la structure de donnees des objets 6. L'interet de cette description 
XML Schema 92 est de constituer une definition de reference unique pour la 
structure des objets 6, modele qui sera utilise chaque fois qu'il sera necessaire de 
verifier la structure ou la validite des objets 6. 

Dans le mode de realisation preferentiel, un certain nombre de definitions 
J ohjcLs utiJisees dans le schema COSSchema 92 sont derivees a partir de definitions 
sftK-kccs dans un autre schema XML Schema 91, denomme COSCoreSchema. 

L'interet de cette approche est de permettre au COS d'uniformiser les 
definitions de certains objets en leur donnant une base commune, et de pouvoir 
cvcntucllement effectuer un certain nombre de travaux, en particulier de 
maintenance, de fa?on homogene sur ces objets. Par exemple, s'il s'avere necessaire 
d'introduire une nouvelle donnee simple ou de modifier une donnee simple existante 
dans un type de base defini dans le COSCoreSchema, il ne sera pas necessaire de. 
reproduire la nouvelle donnee simple ou la modification dans tous les objets bases 
sur ce type, et la modification sera implicitement reproduite via la seule reference au 
type de base. Ainsi, les risques d'erreur au niveau de la structure des objets COS 
seront reduits d f autant, et la maintenance de ces objets s'en trouvera facilitee. 

En revenant a Texemple d'entree d'annuaire vue precedemment, dans le 
mode de realisation prefere de Tinvention, celle-ci sera constituee d ! un objet 6, se 
presentant en langage XML sous la forme suivante : 
<entree_annuaire> 

<nom>OTOOBE</nom> 

<telephone>+33(0)l 44 34 85 03</telephone> 

<telecopie>+33(0)l 44 34 85 01</telecopie> 

<adresse> 

<rue>3bis, rue du Docteur-Foucault</rue> 

<ville>92000 NANTERRE<ville> ; 
</adresse> 
<adresse> 

<rue>34, bd Haussmann</rue> 

<ville>75009 PARIS</ville> 
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</adresse> 

<contact>M. Laurent QUEREL</contact> 
<contact>M. Jean-Francis QUENTIN</contact> 
<contact>M. Gilles ANDRE</contact> 
5 </entree_annuaire> 

Cet objet sera typiquement conforme a un fragment du COSSchema, qui est 
de type XML Schema, se presentant sous la forme suivante : 
<type name- f entree_annuaire M > 

<element name-'nom" minOccurs- '!"> 
1 0 <datatype source="string"> 

<length value="40"/> 
</datatype> 
</element> 

<element name="telephone n minOccurs=" 1 "> 
1 5 <datatype source- 1 string"> 

<length value="15 n /> 
</datatype> 
</element> 

<element name="telecopie" minOccurs= ,, l"> 
20 <datatype source="string"> 

<lengthvalue="157> 
</datatype> 
</element> 

<type name="adresse" minOccurs='T' maxOccurs="*"> 
25 <element name= n rue n minOccurs=" 1 "> 

<datatype source- ! string"> 
<length value="40 n /> 
</datatype> 
</element> 

3 0 <element name-Ville" minOccurs=" 1 M > 

<datatype source-' string n > 
<iength value="40"/> 
</datatype> 
</element> 
35 </type> 

<element name-' contact" minOccurs="0" maxOccurs- '*"> 
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<datatype source="stxing"> 
<length value^MO"^ 
</datatype> 
</element> 
5 </type> 

Dans cette definition XML Schema, le parametre 'minOccurs' d'une donnee 
simple ou d'un sous-objet emboite indique le nombre minimum de fois ou la donnee 
concernee apparait dans Tobjet immediatement contenant, et le parametre 
! maxOccurs f d ! une donnee simple ou d f un sous-objet emboite indique le nombre 
10 maximum de fois ou la donnee concernee apparait dans Tobjet immediatement 
contenant. Par defaut, c'est-a-dire lorsque 'maxOccurs 1 n'apparait pas, il est suppose 
etreegalal. 

La signification de 'maxOccurs^'* m est que la donnee ou le sous-objet 
concerne peut apparaitre un nombre quelconque de fois dans 1'objet immediatement 
15 contenant. 

Dans le mode de realisation prefere de Tinvention, le precede utilise cette 
description au format XML, en association avec le precede de stockage d'objets dans 
seulement deux tables qui a ete decrit plus haut, pour generer automatiquement des 
instructions SQL pour creer et gerer les donnees de la base de donnees 2 representant 

20 les objets stockes. 

Pour cela, le precede de Tinvention part du COSSchema et il applique un 
certain nombre de regies pour obtenir un format XML Schema etendu, denomme 
XDB Schema, comparable a celui de Texemple decrit ci-dessus. En effet, dans le 
COSSchema, la description des donnees est faite, de fa9on structuree, en se referant a 

25 d'autres types predefinis, tels que les types definis dans le COSCoreSchema ou a des 
types intermediaires definis dans le COSSchema lui-meme. Pour rendre utilisables 
dans le langage SQL utilise les informations presentes dans le COS Schema, le 
precede de rinvention, applique done a ce schema COS Schema un certain nombre 
de regies de traduction lui permettant de passer d ! une representation comportant des 

30 types non simples a une representation ne comportant plus que des types simples. Le 
resultat de cette traduction constitue le schema XDB Schema. 

Toutefois, le schema XDB Schema obtenu precedemment n'est pas suffisant 
a lui seul pour definir completement la structure de I'objet 6 dans la base de donnees 
2 : en effet, il manque les informations permettant de definir les donnees de Tobjet 6 

35 qui seront indexees. Pour resoudre ce probleme, le precede de l'invention utilise un 
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schema XML 96 complementaire, denomme XDB Mapping, decrivant les donnees a 
indexer dans les tables stockant les donnees de l'objet 6. 

Ce schema XDB Mapping 96 reprend la structure du schema COSSchema 
en la limitant aux donnees devant faire l'objet d'une indexation. Ainsi, dans l'exemple 
5 precedent ou la donnee "nom" devait etre indexee, le fragment correspondant dans ie 
XDB Mapping sera du type suivant : 
<type name= n entree__annuaire ,, > 

<element name="nom" sqliindexname^IndexNom'' sql:indexType="... n /> 

</type> 

10 ou la rubrique "sqhindexname" indique le nom de 1'index a creer, ici "IndexNom", et 
ou la rubrique "sqlrindexType" sert a indiquer, sous une syntaxe adequate, des 
parametres pour 1'index a creer, tels que "ordre de tri croissant", "pas de distinction 
minuscules/majuscules", etc.. Ainsi, avec ce schema XDB Schema, le procede de 
Tinvention possede toutes les informations utiles pour creer automatiquement dans la 
15 base de donnees 2 toutes les donnees necessaires pour l'objet 6 a creer. 

Ensuite, le procede traduit ces schemas XDB Schema et XDB Mapping en 
instructions SQL k destination du SGBD gerant la base de donnees 2. 

Toutefois, avant de pouvoir mener a bien cette operation, un autre probleme, 
lie aux possibility offertes par les objets, doit etre resolu. En effet, I'approche 
20 orientee objet permet a des donnees simples, ou a des sous-objets, contenus dans des 
sous-objets distincts d'avoir le meme identifiant, pourvu que cet identifiant soit 
unique dans le sous-objet, ou l'objet 6, les contenant immediatement Cette 
possibility de noms dupliques dans des sous-objets differents interdit d'utiliser 
directement ces identifiants comme identifiants globaux de donnees dans la base de 
25 donnees 2, car deux donnees distinctes d'une meme table pourraient alors recevoir le 
meme identifiant, ce qui est interdit par tous les SGBDR existants. 

Pour resoudre ce probleme, le procede cree pour chaque donnee simple un 
identifiant global obtenu en prefixant l'identifiant de la donnee simple, tel qu'il 
apparait dans la rubrique , name="... ,M de la definition de la donnee simple dans le 
30 schema XDB Schema, par la concatenation des identifiants, tels qu'il apparaissent 
dans les rubriques 'name="... m des definitions correspondantes du schema XDB 
Schema, de tous les sous-objets contenant, a xmc niveau ou un autre, la donnee 
simple consid<§ree. Ce procede leve l'ambiguite qui pourrait apparaitre, car du fait que 
les identifiants des donnees simples ou des sous-objets dans leurs objets 
35 immediatement contenant sont distincts, deux identifiants globaux obtenus de cette 
fa9on sont necessairement distincts globalement. 



WO 02/03245 



PCT/FROO/01902 



16 

Ainsi, dans l'exemple ci-dessus, l'identifiant global de la donnee "nom" sera 
"nom" lui-meme, puisque la donnee simple "nom M n ! est pas contenue dans un sous- 
objet ; par contre, l'identifiant global de la donnee "rue" contenue dans le sous-objet 
"adresse" sera " adresse jrue". 
5 Dans ce qui precede, on a indique que les identifiants des donnees creees 

dans les tables 3 et 7 de la base de donnees 2 etait la concatenation des identifiants de 
la donnee et de tous les sous-objets la contenant dans 1'objet 6. Toutefois, cela pose 
probleme en ce que la longueur de ces identifiants est habituellement limitee par les 
SGBDR classiques a une valeur assez basse, de l'ordre de quelques dizaines de 

10 caracteres, et que, pour des objets comportant un niveau d'emboitement meme 
modere, cette limite est tres vite atteinte. 

Pour resoudre ce probleme, le precede de l'invention tronque les identifiants 
precedemment obtenus a la longueur permise par le SGBDR pour les identifiants de 
donnees d'une table. A Tissue de cette troncature, si l'identifiant global obtenu est 

15 deja present dans la table ou il devait etre cree, le precede de l'invention realise les 
etapes suivantes : 

1°/ le dernier caractere alphabetique de l'identifiant global precedemment 
obtenu est remplace par le chififre "0", ainsi que tous les chiffres le suivant 
eventuellement ; 

20 2° I si l'identifiant global ainsi obtenu est encore present dans la table, le 

nombre constitue par Tensemble des chiffres apparaissant a la fin de Tidentifiant 
global est augmente d'une unite et Tetape 2 est repetee tant qu f un nombre entierement 
constitue de chiffres M 9" n f a pas ete atteint ; 

3°/ si un nombre entierement constitue de chiffres "9" est atteint a l'etape 2, 
25 alors le proc6de retourne a Tetape 1 . 

Les etapes 1°/ a 37 precedentes sont repetees jusqu'a ce qu'un identifiant 
global, nouveau dans la table consideree, soit trouve. 

Ainsi, le procede ci-dessus decrit permet de lever les ambiguites, dans les 
identifiants globaux attribues aux donnees simples stockees dans la base de donnees 
30 2, qui peuvent apparaitre du fait de la possibility de duplication d ! un identifiant de 
donnee ou de sous-objet dans des sous-objets distincts. 

En utilisant ce procede de generation d'identifiants globaux pour les donnees 
simples d ! un objet 6, le procede relit alors en parallele le schema XDB Schema et 
XDB Mapping, et pour chaque nouveau type d ? objet a creer 6 trouve dans le schema 
35 XDB Schema, il applique le procede suivant : 
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le procede cree alors dans la base de donnees une table principale 3 
portant le nom de l'objet 6, suivi du suffixe "jmain", comportant une 
donnee "cle" 11 servant a identifier de fafon unique dans la base de 
donnees un objet 6 ; ainsi, lorsqu'il rencontre dans le schema XDB 
Schema la definition : 
<type name="entree_annuaire"> 

</type> 

le procede cr6e la table principale 3 "EntxeeAimuaire_main" 
gorrespondante par l'instruction SQL : 

CREATE TABLE "EnlieeAnnuairejnain" (cle INTEGER, 

PRIMARY KEY (cle)) 
ensuite, le procede explore les definitions "<element ...>...</element>" du 
schema XDB Schema, XDB Schema et pour chaque donnee simple 
rencontree, telles que "nom" ou "contact", il determine si cette donnee est 
en nombre fixe ou variable ; une donnee simple sera dite en nombre fixe 
si sa rubrique "maxOccurs" est absente de la definition et si cette donnee 
simple n ! est pas contenue a un niveau quelconque dans un sous-objet en 
nombre variable, c'est-i-dire un sous-objet dont la rubrique "maxOccurs" 
serait presente et differente de la rubrique "minOccurs" dudit sous-objet ; 
une donnee sera dite en nombre variable dans le cas contraire, c'est-a-dire 
si elle n'est pas en nombre simple au regard de la definition precedente ; 
lorsque le procede rencontre une donnee en nombre fixe telle que la 
donnee "nom" dans 1'exemple ci-dessus, il ajoute cette donnee en nombre 
fixe dans la table principale 3 a 1'aide d'une instruction SQL telle que : 
ALTER TABLE "EntreeAnnuairejnain" ADD nom VARCHAR(40) 
dans laquelle Tidentifiant global "nom" est obtenu par le procede decrit 
plus haut, et dans laquelle la longueur "40" apparaissant dans la rubrique 
"VARCHAR" est reprise de la ! <length value="..."> ! de la definition 
correspondante ; en outre, si le procede trouve dans le schema XDB 
Mapping une definition tfindex portant sur la donnee qtfil vient de creer 
dans la table principale, le procede cree un index pour cette donnee a 
Taide d ! une instruction SQL adequate telle que : 
CREATE INDEX "IndexNom" ON "EntreeAnnuaire_main n (nom) 



WO 02/03245 PCT/FR00/01902 

dans laquelle le nom de l'index n IndexNom ,! est celui retrouve dans la 
rubrique "sqlrindexname" de la definition correspondante du schema 
XDB Mapping ; 

- lorsque le procede rencontre une donnee en nombre variable telle que la 
5 donnee "contact" dans l'exemple ci-dessus, il effectue les operations 

suivantes : 

■ s'il n'existe pas deja nne table annexe 7 associee a cette table 
principale 3, il cree cette table annexe a l'aide d f une instruction SQL 
telle que : 

10 CREATE TABLE "EntreeAnnuaire^annex" (cle INTEGER, 

PRIMARY KEY (cle)) 

■ dans laquelle la donnee "cle" est la donnee servant a identifier de 
fa?on unique un objet 6 dans la base de donnees 2 ; 

■ ensuite, le procede cree la donnee correspondante dans la seconde 
15 table, en lui associant, de la fa9on decrite precedemment, une 

donnee booleenne "presence", permettant de savoir si la donnee 
correspondante est presente ou non dans Tensemble de donnees 71 
considere ; par exemple, pour la donnee en nombre variable 
"contact" 17, cette creation sera realisee a l'aide d'une instruction 
20 SQL telle que: 

ALTER TABLE "EntreeAnnuaire annex" ADD contact 
VARCHAR(40), ADD presence^contact BOOLEAN 

■ dans laquelle l'identifiant global est obtenu par le procede decrit 
plus haut, et dans laquelle longueur "40" apparaissant dans la 

25 rubrique "VARCHAR" est reprise de la rubrique ^length 

value^"... 1 ^ 1 de la definition correspondante dans le schema XDB 
Schema ; 

■ dans le cas d'une donnee incluse dans un sous-objet comme la 
donnee "rue", Tidentifiant global sera obtenu comme indique 

30 precedemment, et Tinstruction SQL correspondante sera, par 

exemple : 

ALTER TABLE "EntreeAimuaire^annex" ADD adresse_rue 

VARCHAR(40), ADD presence_adresse_rue BOOLEAN. 
Le procede repete les operations precedentes jusqu f a ce que toutes les 
35 definitions presentes dans le schema XDB Schema 61 aient <Ste traitees. A Tissue de 
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ce traitement, le procede aura done cree automatiquement la structure d'objets 6 dans 
la base de donnees 2, telle qu'elle etait decrite dans le schema COS Schema. 

Dans le mode de realisation de la presente invention, les aspects ci-dessus 
du procede de l'invention sont implements dans un programme 90 denomme XBD 
5 Engine, et, contrairement a la technique anterieure, le procede de rinvention permet 
de realiser la creation de nouveau type d'objet 6 dans la base de donnees 2 sans 
intervention manuelle d'un operateur, ce qui se traduit par un gain de temps tres 
appreciable et une diminution considerable du risque d'erreur, tant pour la creation 
que pour la modification, dans la base de donnees, de la structure d'un objet 6. 

10 Dans ce qui precede, on a decrit le procede de 1'invention comme 

transformant le schema COSSchema, comportant des types predefinis, en un schema 
XML, le schema XDB Schema, ne comportant plus que des types de donnees simples 
tels qu'utilises par le SGBDR. Cela a ete fait dans l'optique de rutilisation d'un 
langage SQL de base, qui ne connait pas de types autres que ces types simples. 

15 Toutefois, dans le cas de l'utilisation d f un langage SQL evolue, tel que le 

langage SQL 3, le procede de rinvention tirera naturellement parti des possibilites de 
typage offertes par ce langage en ne traduisant en types plus simples que les types ne 
pouvant pas etre "compris" directement par le langage SQL utilise. Les types utilises 
par le COS Schema et pouvant etre traduits directement en types SQL, le seront a 

20 l'aide d r une instruction SQL adequate, telle que : 
CREATE TYPE... 

Dans ce qui precede, on a decrit sur un exemple les etapes de creation d'un 
nouveau type d'objet 6 a stocker dans la base de donnees 2, tant dans la technique 
anterieure que dans le procede de rinvention. Les informations contenues dans 
25 COSSchema et XDBSchema seront bien evidemment reutilisees pour modifier la 
structure d'un objet 6 deja existant dans la base de donnees 2, apres que les 
modifications voulues y aient ete apportees. Cette modification de la structure d'un 
type d'objet 6 deja existant est en tout point similaire a; la creation precedemment 
decrite. Ainsi, par exemple, pour modifier une table 3\ existante et y ajouter un 
30 nouveau champ, l'instruction SQL utilisee, tant dans la technique anterieure que dans 
le procede de l'invention : 

CREATE TABLE ... 
sera remplacee, par exemple, par l'instruction SQL : 

ALTER TABLE "EntreeAnnuaire^main" ADD telex VARCHAR(15), 
35 DROP telecopie 
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qui indique qu'une donnee "telex" sur quinze caracteres doit. etre ajoutee et que la 
donnee "telecopie" doit etre supprimee. 

De meme, la suppression de l'index sur la donnee "nom" dans la table 3 se 
ferait, tant dans la technique anterieure que dans le procede de l'invention, par 
5 Tinstruction SQL : 

DROP INDEX EntreeAnnuaire.IndexNom 

Dans le cas du procede de l'invention, a nouveau ces modifications sont 
effectuees de fa9on automatique par le programme XDB Engine. 

Compte-tenu de ces similitudes, la modification de la structure d'un objet 6 
1 0 stocke dans la base de donnees 2 par le procede de Finvention ne sera pas decrite plus 
en detail. 

Dans ce qui suit, on va maintenant decrire le fonctionnement du procede 
selon la presente invention en comparaison avec la technique anterieure pour le 
stockage et la gestion des donnees en nombre variable d'un objet 6. 
.15 En se referant aux figures 2 et 3, un systeme de stockage des donnees 

simples d f un objet 6, dans la technique anterieure comme dans le procede de 
Tinvention, est constitue d f un ordinateur 1 hebergeant une base de donnees 
relationnelle 2. Les ensembles de donnees simples d'une table principale telle que la 
table principale 3, ou ceux d'une table annexe telles que les tables 4, 5 ou 7, sont 
20 geres a Taide des fonctions offertes par le systeme de gestion de base de donnees 
relationnelle ou SGBDR, utilise pour la gestion de la base de donnees 2. 

Ces fonctions comprennent au minimum une fonction d ! ecriture ou de 
creation d'un ensemble de donnees simples dans une table, une fonction de lecture 
d f un ensemble de donnees simples depuis une table, une fonction de suppression d'un 
25 ensemble d'une table, et une fonction de recherche d'un ensemble par son contenu, la 
fonction de modification d'un ensemble pouvant etre assimilee, pour la simplicite de 
. Texpose, a une lecture de l'ensemble suivie d'une ecriture de l'ensemble modifie. Par 
consequent, cette fonction ne sera pas decrite davantage. 

Dans ce qui suit, on va comparer les performances, en termes de nombres 
30 d'ensembles de donnees echanges avec la base de donnees 2, respectivement pour la 
technique anterieure et le procede de Tinvention. 

En se referant a la figure 3, dans la technique anterieure, la base de donnees 
2 comporte une table principale 3 stockant les ensembles 3 1 de donnees simples en 
nombre fixe "nom" 12, "telephone" 13 et "telecopie" 14, et cette table principale est 
35 en relation avec deux tables annexes 4 et 5 contenant les ensembles 41 et 51 de 
donnees simples en nombre variable, respectivement les ensembles 41 constitues des 
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donnees simples "rue" 15 et "ville" 16 pour la table annexe 4, et les ensembles 51 
constitues de la donnee "contact" 17 pour la table annexe 5. 

De facon classique, une donnee ^identification unique "cle" 11, presente 
dans les ensembles 31, 41 et 51 respectivement stockes dans les tables 3, 4 et 5, est 
5 utilisee pour mettre en relation, c'est-a-dire faire se referencer, la table principale 3 et 
les tables annexes 4 et 5. 

1 °l Ecriture d'un objet 6 dans la base de donnees 2 

L'ecriture, ou creation, d'un objet identifie par une valeur unique telle que 
1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
1 0 -idccopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et "contact" 17 en 
nombre variable, comportera classiquement les etapes suivantes : 

- ecriture de l'ensemble principal 31 constitue des donnees simples "cle" 
11. "nom" 12, "telephone" 13 et "telecopie" 14 dans la table 3 a l'aide de 
la fonction correspondante du SGBDR, en initialisant la donnee "cle" 1 1 
j5 a la valeur 1234 ; cela pourra etre realise, par exemple, a l'aide d'une 

instruction SQL telle que : 

INSERT INTO "EntreeAnnuaire_main" (cle, nom, telephone, telecopie) 
VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 
01") 

20 - ecriture de deux ensembles 41 constitues des donnees simples en nombre 

variable 15 et 16 a l'aide de la fonction correspondante du SGBDR, en 
initialisant dans chacun la donnee "cle" 11 a la valeur 1234, c'est-a-dire, 
ecriture des deux ensembles 41 1 et 41 2 constitues respectivement des 
donnees simples "cle" 11, "rue" 15 u "ville" 16! d'une part, et des donnees 

25 simples "cle" 11, "rue" 15 2 , "ville" 16 2 d'autre part ; cela pourra gtre 

realise, par exemple, par les instructions SQL : 

INSERT INTO "EntreeAnnuaire_l" (cle, rue, ville) VALUES (1234, 
"3bis, rue du Docteur-Foucault", "92000 NANTERRE") 
et : 

30 INSERT INTO "EntreeAnnuaire_l " (cle, rue, ville) VALUES (1234, "34, 

bd Haussmann", "75009 PARIS") 
- ecriture de trois ensembles 51 a l'aide de la fonction correspondante du 

SGBDR, en initialisant la donnee "cle" 11 a la valeur 1234, c'est-a-dire, 

ecriture des trois ensembles 51 t , 51 2 et 51 3 constitues respectivement des 
35 donnees simples "cle" 11 et "contact" 17 t pour le premier, des donnees 

simples "cle" 11 et "contact" 17 2 pour le second, et "cle" 11 et "contact" 
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17j pour le troisieme ; cela pourra etre realise, par exemple, par les 
instructions SQL : 

INSERT INTO "EntreeAnnuaire_2" (cle, contact) VALUES (1234, "M. 
Laurent QUEREL") 

5 INSERT INTO "EntreeAnnuaire_2" (cle, contact) VALUES (1234, M M. 

Jean-Fran?ois QUENT1N") 
et: 

INSERT INTO "Entree Annuaire_2" (cle, contact) VALUES (1234, "M. 
Gilles ANDRE") 

10 On constate que, dans la technique anterieure, on effectue done une 

operation d'ecriture pour stocker l'ensemble 31, deux operations d'ecriture pour 
stocker les ensembles 41, et trois ecritures pour stocker les ensembles 51, soit un 
total de six ecritures pour stocker l'ensemble des donnees correspondant a l'objet a 
stocker 6. 

15 2°/ Lecture d'un objet 6 dans la base de donnees 2 

La lecture d ! un objet 6, ayant pour donnee unique "cle" 11 une valeur 
donnee telle que 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et 
"contact" 1 7 en nombre variable, se fera classiquement par les etapes suivantes : 
20 - lecture, a l'aide de la fonction correspondante du SGBDR, de l'ensemble 

principal 31, constitue des donnees simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donnee "cle" 11 a la valeur 
donnee 1234 ; cela pourra etre realise, par exemple, a Taide de 
Tinstruction SQL : 

25 SELECT * FROM "EntreeAnnuaire_main" WHERE cle=1234 

- lecture, Taide de la fonction correspondante du SGBDR, de tous les 
ensembles 41 de la table 4 comportant la valeur 1234 dans leur donnee 
"cle" 11, c f est-a-dire, lecture des deux ensembles 41! et 41 2 constitues 
respectivement des donnees simples "cle" 11, "rue" 15i, "ville" 16i d ! une 

30 part, et des donnees simples "cle" 11, "rue" 15 2 , "ville" 16 2 d'autre part ; 

cela pourra etre obtenu, par exemple, a Taide de Tinstruction SQL : 
SELECT * FROM "EntreeAnnuaire__l" WHERE cle=1234 
cette instruction retrouvera alors les dexix ensembles de donnees 41 1 et 
41 2 ; 

35 - lecture des ensembles 51 a Taide de la fonction correspondante du 

SGBDR, en relisant tous les ensembles 51 de la table 5 comportant la 
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valeur donnee 1234 dans leur donnee "cle" 11, c'est-a-dire, lecture des 
trois ensembles 5\ u 51 2 et 51 3 constitues respectivement des donnees 
simples "cle" 11 et "contact" 17i pour le premier, des donnees simples 
"cle" 1 1 et "contact" 17 2 pour le second, et "cle" 1 1 et "contact" 17i pour 
5 le troisieme; cela pourra etre obtenu, par exemple, a l'aide de 

l'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_2" WHERE cle=1234 

cette instruction retrouvera alors les trois ensembles de donnees 5 1 1 , 5 1 2 

et51 3 . 

10 De meme que pour l'operation d'ecriture, on constate que, dans la technique 

anterieure, on effectue done au total de six operations de lecture d'ensemble de 
donnees dans les tables 3, 4 et 5 pour relire l'ensemble des donnees correspondant a 
l'objet 6 a relire. 

3°/ Suppression d'un objet 6 dans la base de donnees 2 

15 La suppression d'un objet, constitue des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, ayant pour donnee "cle" 11 une valeur donnee, 
par exemple 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples en nombre variable 
"rue" 15, "ville" 16 et "contact" 17, se composera classiquement des etapes 

20 suivantes : 

- suppression de l'ensemble principal 31 ayant pour donnee "cle" 11 la 
valeur donnee 1234 a l'aide de la fonction correspondante du SGBDR ; 
cela pourra etre realise, par exemple, a l'aide de l'instruction SQL : 
DELETE FROM "EntreeAnnuaire_main" WHERE cle=1234 

25 - suppression des ensembles 41 ayant comme donnee "cle" 11 la valeur 

donnee 1234 a l'aide de la fonction correspondante du SGBDR, e'est-a- 
dire, suppression des deux ensembles 41 1 et 4h constitues 
respectivement des donnees simples "cle" 11, "rue" 15i, "ville" 16j d'une 
part, et des donnees simples "cle" 11, "rue" 15 2 , "ville" 16 2 dautre part ; 

30 cela pourra etre realise, par exemple, a Taide de Tinstruction SQL : 

DELETE FROM "EntreeAnnuaire_l " WHERE cle=l 234 

- suppression des ensembles 51 ayant comme donnee "cle" 11 la valeur 
donnee 1234 a l'aide de la fonction correspondante du SGBDR, c ! est-a- 
dire, suppression des trois ensembles 51 1, 51 2 et 5h constitues 

35 respectivement des donnees simples "cle" 11 et "contact" 17i pour le 

premier, des donnees simples "cle" 11 et "contact" 17 2 pour le second, et 
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"cle" 11 et "contact" 17 3 pour le troisieme ; cela pourra etre realise, par 
exemple, a l'aide de rinstraction SQL : 
DELETE FROM "EntreeAnnuaire_2" WHERE cle=l 234 
De meme que pour les operations d'ecriture ou de lecture, on constate que, 
5 dans la technique anterieure, on effectue au total de six operations de suppression 
d f ensemble de donnees dans les tables 3, 4, et 5 pour supprimer l'ensemble des 
donnees correspondant a l'objet 6 a supprimer, 

4°/ Recherche d f un objet 6 dans la base de donnees 2 

Toujours dans la technique anterieure, la recherche d ! un objet ayant, par 
0 exemple, pour donnee 12 "norn" la valeur "OTOOBE", et comportant un ensemble 
31 de donnees simples en nombre fixe "nom" 12, "telephone" 13, "telecopie" 14 
.a**-»ciee$ aux donnees simples "rue" 15, "ville" 16 et "contact" 17 presentes dans les 
ensembles 41 et 51, sera constitute classiquement des etapes suivantes : 

- recherche, a l'aide de la fonction correspondante du SGBDR, de 
l'ensemble principal 31, constitue des donnees simples "cle" 11, "nom" 
1 2. "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" donnee ; cela pourra etre realise, par exemple, h l'aide 
de Instruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE nom-"OTOOBE" 

- lecture, a l'aide de la fonction correspondante du SGBDR, de tous les 
ensembles 41 de la table 4 ayant, dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de l'ensemble 31 venant d'etre retrouve 
dans la table 3, e'est-a-dire, lecture des deux ensembles 41 x et 41 2 
constitues respectivement des donnees simples "cle" 11, "rue" 15i, "ville" 
16j d'une part, et des donnees simples "cle" 11, "rue" 15 2 , "ville" 16 2 
d'autre part ; en supposant que la valeur contenue dans la donnee "cle" 1 1 
de Tensemble 31 retrouve precedemment soit egale a 1234, cela pourra 
etre obtenu, par exemple, a Taide de Tinstruction SQL : 
SELECT * FROM "EntreeAnnuaire_l " WHERE cle=1234 

- lecture, a Taide de la fonction correspondante du SGBDR, de tous les 
ensembles 51 de la table 5 ayant dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 1 1 de Tensemble 31 venant d'etre retrouve 
dans la table 3, e'est-a-dire, lecture des trois ensembles 51 1, 51 2 et 51 3 
constitues respectivement des donnees simples "cle" 11 et "contact" 17 \ 
pour le premier, des donnees simples "cle" 11 et "contact" 17 2 pour le 
second, et "cle" 11 et "contact" 17i pour le troisieme ; en supposant 
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toujours que la valeur contenue dans la donnee 1 "cle" de Tensemble 31 
retrouve soit egale a 1234, cela pourra etre obtenu, par exemple, a l'aide 
de Tinstruction SQL : 

SELECT * FROM "EntreeAnnuaire_J2" WHERE cle=1234 
5 De meme que pour les operations d'ecriture, de lecture ou de suppression, on 

constate que, dans la technique anterieure, on relit au total de six ensembles de 
donnees depuis les tables 3, 4 et 5 pour retrouver l'ensemble des donnees 
correspondant a l'objet 6 recherche. 

En se referant maintenant a la figure 2, dans le procede de l'invention, la 

10 base de donnees 2 comporte une table principale 3 stockant les ensembles 31 de 
donnees simples en nombre fixe "cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, 
et cette table principale est en relation avec une unique table annexe 7 contenant les 
ensembles 71 de donnees simples en nombre variable, constitues des donnees 
simples "contact" 17. De fa?on classique, une donnee ^identification unique "cle" 

15 11, presente dans les ensembles 31 et 71 respectivement stockes dans les tables 3 et 
7, est utilisee pour mettre en relation, c'est-a-dire faire se references la table 
principale 3 et la table annexe 7, et pour identifier de fa9on unique un objet 6 dans la 
base de donnees 2. 

1 °/ Ecriture d'un objet 6 dans la base de donnees 2 

20 L'ecriture, ou creation, d r un objet identifie par une valeur unique telle que 

1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
"telecopie" 14, associees aux donnees simples "rue" 15, "yille" 16 et "contact" 17 en 
nombre variable, comportera, dans le procede de l'invention, les etapes suivantes : 

- ecriture de l'ensemble dlnformations principal 3 1 , constitue des donnees 
25 simples "cle" 1 1, "nom" 12, "telephone" 13 et "telecopie" 14, a Taide de 

la primitive adequate du SGBDR, ce qui conduit a une operation 
d ! ecriture pour cet ensemble 31 ; en supposant toujours que la valeur 
pour la donnee "cle" 11 soit 1234, cela pourra etre realise a l'aide d'une 
instruction SQL telle que : 
30 INSERT INTO "EntreeAnnuaire main" (cle, nom, telephone, telecopie) 

VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 

01") 

- stockage de la valeur 1234 dans les donnees "cle" 11 des trois ensembles 
de donnees simples 71 1, 71 2 , 71 39 stockage de la premiere donnee "rue" 

35 dans la donnee 15i de Tensemble 71 1 de la table 7, stockage de la 

premiere donnee "ville" dans la donnee 16i de l f ensemble 71 1, stockage 
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de seconde donnee "rue n dans la donnee 15 2 de l'ensemble 71 2 , stockage 
^ la seconde donnee ,! ville M dans la donnee 16 2 de l'ensemble 71 2 , 
stockage de la premiere donnee "contact" dans la donnee 17 \ de 
l'ensemble 71 1, stockage de la seconde donnee "contact" dans la donnee 
5 17 2 de l'ensemble 71 2 , et stockage de la troisieme donnee "contact" dans 

la donnee 173 de l'ensemble 71 3 ; 
- initialisation de la donnee 20i a la valeur booleenne VRAI puisque les 
donnees simples "rue" 15i et "ville" 16i correspondantes sont presentes 
dans l'ensemble 71 i, initialisation de la donnee 21 j a la valeur VRAI 

10 puisque la donnee "contact" 17i correspondante est presente dans 

l'ensemble 71 \ 9 initialisation de la donnee 20 2 a la valeur VRAI puisque 
les donnees simples "rue" 15 2 et "ville" I62 correspondantes sont 
presentes dans l'ensemble 71 2 , et initialisation de la donnee 2 1 2 a la 
valeur VRAI puisque la donnee "contact" 17 2 correspondante est 

• 1 5 presente dans l'ensemble 71 2 ; par contre, initialisation de la donnee 20 3 a 

la valeur FAUX puisque les donnees simples "rue" 15 3 et "ville" I63 
correspondantes sont absentes de l'ensemble 71 3 ; enfm, initialisation de 
la donnee 21 3 a la valeur VRAI puisque la donnee "contact" 17 3 
correspondante est bien presente dans l'ensemble 71 3 ; 

20 - ecriture les trois ensembles 71 1, 71 2 , 71 3 dans la base de donnees 2 a 

l'aide d'instructions SQL telles que : 

INSERT INTO "EntreeAnnuaire annex" (cle 5 presence_adresse, 

presence_contact 3 rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "3bis, rue du Docteur-Foucault", "92000 NANTERRE", 
25 "M. Laurent QUEREL") 

INSERT INTO "EntreeAnnuake_annex" (cle, presence_adresse, 
presence_contact, rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "34, bd Haussmann", "75009 PARIS", "M. Jean-Fran 5 ois 
QUENTIN") 

30 et: 

INSERT INTO "EntreeAnnuaire__annex" (cle, presence_adresse, 

presence^contact, rue, ville, contact) VALUES (1234, FALSE, 
TRUE, "", "M. Gilles ANDRE") 
Ainsi, dans le procede selon 1'invention, le nombre d'ecritures dans la base 
35 de donnees 2 est egal a quatre, au lieu de six dans la technique anterieure. 
2°/ Relecture d'un objet 6 dans la base de donnees 2 
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La lecture d'un objet 6, ayant pour donnee unique "cle" 11 une valeur 
donnee telle que 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et 
"contact" 17 en nombre variable, se fera, dans le procede de Tinvention, par les etapes 
5 suivantes : 

- lecture, a Taide de la fonction correspondante du SGBDR, de Tensemble 
principal 31, constitue des donnees simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donnee "cle" 11 a la valeur 
donnee 1234, ce qui conduit a une operation de lecture pour cet 
10 ensemble ; cette operation de lecture pourra etre realisee, par exemple, a 

Taide de Tinstruction SQL : 

SELECT * FROM "EntreeAnnuaire^main" WHERE cle=1234 

a Taide des donnees presentes dans Tensemble 31, le proced6 de 

Tinvention restitue les donnees fixes de Tobjet 6 ; plus precisement, le 

15 procede initialise la donnee en nombre fixe "nom" de Tobjet 6 a Taide de 

la donnee 12 presente dans Tensemble 31 relu, il initialise la donnee en 
nombre fixe "telephone" de Tobjet 6 a Taide de la donnee 13 de ce meme 
ensemble, et il initialise la donnee en nombre fixe "telecopie" de Tobjet 6 
a Taide de la donnee 14 ; 

20 - lecture, dans la table 7, des ensembles 71 de cette table comportant la 

valeur 1234 dans leur donnee "cle" 11 ; cela pourra etre realise a Taide 
d'un instruction SQL telle que : 

SELECT * FROM "EntreeAnnuaire_annex" WHERE cle=1234 
les trois ensembles de donnees 71 1, 71 2 , 71 3 sont ainsi relus, moyennant 
25 trois operations de lecture d'ensemble de donnees dans la base de donnees 

2; 

ainsi que cela a ete decrit precedemment, ces trois ensembles 71 1, 71 2 , 

7h de donnees sont chacun constitues de la donnee "cle" 1 1, des donnees 

simples en nombre variable "rue" 15, "ville" 16 et "contact" 17, et des 
30 donnees 20 et 21 indiquant respectivement la presence ou non de 

Tensemble en nombre variable "rue", "ville" et de la donnee en nombre 

variable "contact" dans Tensemble 71 concerne ; 
- reconstitution des donnees variables de Tobjet 6 a Taide des donnees 

presentes dans les ensembles de donnees 71 1> 71 2, 71 3 precedemment 
35 relus ; pour cela, le procede examine les donnees 20 et 21 dans chaque 

ensemble 71 1, 71 2 > 71 3 relu ; 
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plus precisement, si le contenu de la donnee booleenne 20 1 
contenue dans Tensemble 71 1 est VRAI, cela signifie qu'il existait a 
Torigine un premier ensemble "rue", "ville" dans l'objet 6 stocke ; 
dans ce cas, le proc6de selon Tinvention creera alors un premier 
sous-objet en nombre variable "adresse" dans Tobjet 6 ; il remplira 
les donnees en nombre variable "rue" et "ville" de ce premier sous- 
objet avec respectivement les donnees 15i et 16i contenues dans 
Tensemble 71 1 ; de meme, si le contenu de la donnee booleenne 21 1 
est vrai, cela signifie qu'il existait a Torigine une premiere donnee 
en nombre variable "contact" dans l'objet 6 ; dans ce cas, le procede 
de Tinvention creera une premiere donnee en nombre variable 
"contact" dans l'objet 6 ; 

en utilisant la meme demarche que ci-dessus, le procede de 
Tinvention creera un second et un troisieme sous-objet "adresse" en 
nombre variable "rue", "ville" si les contenus des donnees 
booleennes 2O2 et 2O3 contenues respectivement dans les ensembles 
71 2 et 7h sont VRAI, et il initialisera les donnees "rue" et "ville" 
de ces second et troisieme sous-objets en nombre variable "adresse" 
avec les donnees respectivement 152 et I62 d'une part, et 153 et I63 
d'autre part respectivement contenues dans l'ensemble 7h et 
Tensemble 7I3 ; 

de meme, le procede de Tinvention creera une seconde et une 
troisieme donnee en nombre variable !' contact" si les contenus des 
donnees booleennes 2I2 et 21 3 contenues respectivement dans les 
ensembles 71 2 et 71 3 sont VRAI, et il initialisera ces seconde et 
troisiemes donnees en nombre variable "contact" avec les donnees 
17 2 et 173 respectivement contenues dans Tensemble 71 2 et 
Tensemble 71 3 ; 

en supposant que les donnees relues proviennent de Texemple 
d'ecriture d'objet 6 precedemment decrit, les donnees simples 20i, 
2O2, 21i,2l2 et2b seront a la valeur VRAI, tandis que la donnee 
2O3 sera a la valeur FAUX ; dans ces conditions, le procede de 
Tinvention reconstituera exactement deux ensembles de donnees 
"adresse" en nombre variable dans l'objet 6 relu, ainsi que trois 
donnees en nombre variable "contact" ; Tobjet 6 d'origine sera done 
parfaitement reconstitue. 
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Pour relire l'objet 6, le procede effectue done au total trois operations de 
lecture d ! ensembles de donnees dans la base de donnees 2, contre six pour la 
technique anterieure. 

3°/ Suppression d'objet 6 dans la base de donnees 2 
5 La suppression d'un objet ayant pour donnee "cle" 1 1 une valeur donnee, par 

exemple 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples en nombre variable 
"rue" 15, "ville" 16 et "contact" 17, se composera, dans le procede de l'invention, des 
etapes suivantes : 

10 - suppression de Tensemble principal 31, constitue des donnees simples 

"cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, ayant pour donnee 
"cle" 1 1 la valeur donnee 1234, a Taide de la fonction correspondante du 
SGBDR ; cela pourra etre realise, par exemple, a l'aide de rinstruction 
SQL: 

1 5 DELETE FROM "EntreeAnnuake jtnain" WHERE cie=l 234 

- suppression de l'ensemble annexe 71, ayant pour donn6e "cle" 11 la 
valeur donnee 1234, a l'aide de la fonction correspondante du SGBDR ; 
cela pourra etre realise, par exemple, a l'aide de rinstruction SQL : 
DELETE FROM "EntreeAnnuaire_annex" WHERE cle=1234 

20 A nouveau, le nombre d'operations de suppression d f ensembles de donnees 

par le SGBDR s'eleve a un total de quatre dans le procede de l'invention, contre six 
dans la technique anterieure. 

4°/ Recherche d ! un objet 6 dans la base de donnees 2 

- recherche, a l'aide de la fonction correspondante du SGBDR, de 
25 Tensemble principal 31, constitue des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" donnee ; cela pourra etre realise, par exemple, a Taide 
de rinstruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE nom="OTOOBE" 
30 - lecture, a Taide de la fonction correspondante du SGBDR, de tous les 

ensembles 71 de la table 7 ayant, dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de Tensemble 31 venant d ! etre retrouve 
dans la table 3, e'est-a-dire, lecture des trois ensembles 71 1, 712 et 71 3 
ayant la structure de donnees precedemment decrite ; en supposant que la 
35 valeur contenue dans la donnee "cle" 11 de l'ensemble 31 retrouve 
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precedemment soit egale a 1234, cela poun-a 6tre obtenu, par exemple, a 
Taide de Tinstruction SQL : 

SELECT * FROM "EntreeAnnuaire^annex" WHERE cle=1234 
- reconstitution des donnees ou des sous-objets en nombre variable de 
5 Tobjet 6 a relire a Taide des donnees contenues dans les trois sons- 

ensembles relecture ; cette reconstitution est identique a celle decrite au 
paragraphe 2°/ ci-dessus ; en consequence, elle ne sera pas decrite plus en 
detail. 

A nouveau, le nombre d'operations de recherche d'ensembles de donnees par 
10 le SGBDR s'eleve a un total de quatre dans le procede de l'invention, contre six dans 
la technique anterieure. 

Ainsi, dans les quatre operations de base effectuees par un SGBDR, 
Tutilisation du procede de Tinvention permet une reduction d ! un tiers du nombre 
^operations d'ensembles de donnees dans tous les cas. L'exemple presente ci-dessus, 
1 5 volontairement simple pour des raisons de clarte de Texpose, ne rend pas 
necessairement bien compte des gains tres importants que peut apporter le procede 
dans un cas pratique comportant un nombre tables en relation beaucoup plus 
important. 

Dans un cadre plus general, on designe, dans ce qui suit, par N a le nombre 
20 de tables annexes T l9 par N p le nombre total d'ensembles principaux 3 1 dans la table 
principale 3, et par K,y pour i variant de 1 a N a? le nombre total d'ensembles de 
donnees presents dans une table annexe TV 

Avec ces conventions, dans la technique anterieure, le nombre moyen 
d'operations pour effectuer une entree-sortie concernant un objet 6 dans une table Ti 
25 donnee sera, en moyenne, egal a Ki/N a , et le total general pour une entree-sortie 
complete comprenant Tensemble principal 31 et les N a ensembles de donnees 
presents dans les N a tables annexes Tj sera done egal a : 

Na 

.N.„t= 1 + 2 Ki/Np 

i=I 

30 Dans le cas du procede de la presente invention, le nombre d'entrees-sorties 

necessaire pour obtenir les ensembles de donnees contenus dans Tunique table 
annexe sera done egal en moyenne a Max (Ki)/Np> du fait que Tunique table annexe 
comporte un nombre d'ensembles egal au maximum des nombres d ! ensembles 
presents dans les ensembles d'ensembles en relation ; par consequent, le total general 
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pour une entree-sortie complete comprenant Tensemble principal 31 et les ensembles 
de donnees contenus dans Tunique table annexe sera done egal a : 

Na 

N pro c=l + Max(Ki)/N p 

5 On voit que sauf circonstance tres exceptionnelle, le nombre moyen 

d'entrees-sorties N pr0 c avec le precede de la presente invention sera touj ours tres 
inferieur au nombre moyen d'entrees-sorties N an t sans ce procede. Dans le cas 
favorable, mais relativement frequent, ou le nombre d'ensembles de donnees est 
sensiblement le meme dans les diverses tables annexes, le procede selon Tinvention 
1 0 permet un gain en performances atteignant un facteur egal au rapport N pr0 c/Nant, e'est- 
a-dire : 

Na 

1+ Max(Ki)/N P 

4=1 

1-f 2 Ki/Np 

soit en utilisant ITiypothese que les divers Ki sont sensiblement egaux entre eux, et 
1 5 done au maximum dentre eux : 

Na 1 

l + Max(Ki)/N P 
m 

H-NoxMax(Ki)/N P 
i=i 

soit en negligeant 1 devant M^x (Ki)/N p9 un rapport de valeur 1/N a , ce constitue une 
diminution tres importante du nombre d'entrees-sorties des que le nombre de tables 
annexes augmente. 

20 Ce procede est done particulierement souhaitable dans toutes les 

applications de bases de donnees relationnelles dans lesquelles les performances 
constituent un facteur critique, telles que les applications temps reel ou celles 
utilisant des serveurs de bases de donnees tres soilicites, comme ceux qui se 
rencontrent dans les reservations centralisees par un reseau, ou dans la consultation 

25 de bases de donnees via le reseau mondial Internet 

En outre, rutilisation du langage XML pour representer les objets stockes 
dans la base de donnees 2 permet l'utilisation de patrons dobjets XML pour filtrer 
certaines donnees des objets 6 entrants et sortants de la base de donnees 2. .Ainsi, 
dans le mode de realisation prefere de la presente invention, des patrons d'objets 
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XML 61 , collectivement denommes I/O Format et conformes a une description XML 
Schema, sont utilises pour realiser un tel filtrage. 

Plus precisement, ces patrons d'objets XML I/O Format 61 supprimeront 
certaines donnees sensibles des objets entrants, conune des donnees concernant la 
5 validity des donnees contenues dans un objet 6, de fa?on a ce que ces donnees 
sensibles ne puissent etre, en tout etat de cause, modifiees depuis le reseau 60, et a ce 
que leur modification ne puisse etre effectuee que par un operateur intervenant 
directement sur l'ordinateur serveur 1 . 

De meme, les patrons d'objets XML I/O Format 61, en fonction des donnees 

10 effecti vement utilisees par un utilisateur sur le reseau 60, supprimeront dans les 
donnees d f un objet 6 transmises sur le reseau 60 les donnees qui ne seraient pas 
utilisees par ledit utilisateur. Compte-tenu de ce que, dans la pratique, les donnees 
transmises pour un objet 6 ne represented habituellement qu'une faible partie de 
Tensemble des donnees de cet objet, ce procede permet une reduction substantielle du 

15 volume des donnees transmises par l'ordinateur serveur 1, ce qui est particulierement 
interessant dans le cas d'ordinateur serveur 1 tres charge, tels que ceux qui se 
rencontrent dans Tlntemet. 

En outre, ce procede permet de prendre en compte differents niveaux de 
securite attaches aux utilisateurs se connectant via le reseau 60, en associant a chaque 

20 niveau de securite un patron eliminant des donnees transmises a l'utilisateur les 
donnees non autorisees pour le niveau de securite de l'utilisateur. 

En outre, du fait que ce procede garantit que seules les donnees conformes 
au patron d f objet I/O Format 61 utilise seront transmises, il n'y aura pas lieu de 
demander la restitution par la base de donnees 2, des donnees eliminees par le patron 

25 d'objet I/O Format 61 utilise, et ainsi les donnees apparaissant dans les requetes SQL 
"SELECT" effectuees par le moteur COS Engine pourront etre limitees axix seules 
•donnees transmises, ce qui diminuera de fa9on toute aussi sensible* la charge 
d'entrees-sorties dans la base de donnees 2 dans Tordinateur serveur 1 . 

Ce procede permet de focaliser la requete sur les tables de la base de 

30 donnees 2 et les donnees dans ces tables 3 et 7 qui sont effectivement utilisees dans 
la requete d f un utilisateur. Ainsi, dans le cas ou aucune donnee de la table annexe 7 
n'est utilisee dans la requete, le procede n'accedera pas a cette table 7 pour la requete, 
ce qui, a nouveau, permettra d'ameliorer sensiblement les perfomiances de 
Tordinateur serveur 1 mettant en ceuvre le procede de Tinvention. 

35 Ainsi, Tutilisation du format XML et d ! un patron d ! objet au format XML 

permet d ! imposer des regies de securite sur les donnees entrantes, de limiter 
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l'utilisation de la base passante du reseau 60 avsx seules donntes necessaires et de 
diminuer en due proportion le volume des donnees echangees avec la base de 
donnees 2. 

Dans le mode de r6alisation decrit ci-dessus 5 la donnee "cle" 11, identifiant 
5 de facon unique un objet 6, a ete indiquee, pour des raisons de simplicite de l'expose, 
comme etant geree de facon explicite par le procede de l'invention. Toutefois, cette 
technique explicite n'est en aucune maniere obligatoire, et elle peut parfaitement etre 
remplacee par toute autre technique equivalente pouvant etre offerte par le SGBDR 
utilise. 

1 o De meme, cette donnee "cle" 11 a ete decrite comme etant constituee d'un 

scul nombre entier, mais elle peut tout aussi bien etre constituee de plusieurs parties. 
Par exemple, dans le mode de realisation prefere de l'invention, une donnee "cle" 11 
unique, appelee Object IDentifier ou ODD, est obtenue pour chaque objet 6 en 
concatenant une premiere partie constitute du nom logique du serveur 1 sur lequel 

15 reside la base de donnee 2, une seconde partie constitute du numero de la table 
principalc 3 dans la base de donnee 2, et une troisieme partie constituee du numero 
d'enrcgistrement de l'ensemble de donnees principal 3 1 dans ladite table 3. 

Le nom logique du serveur 1 etant unique sur le reseau 60, la base de 
donnees 2 etant unique sur le serveur 1 ou elle est stockee, le numero de la table 3 

20 etant unique dans la base de donnees et le num6ro d'enregistrement de l'ensemble de 
donnees principal 3 1 etant unique dans la table 3, l'OID 1 1 ainsi obtenu pour un objet 
6 sera done unique parmi l'ensemble des OID identifiant les objets 6 accessibles via 
le reseau 60. En outre, ce type de donnee "cle" 1 1 presentera l'interet de permettre de 
localiser precisement le lieu de stockage d'un objet 6 quelconque sur la seule base de 

25 son OID 1 1 associe. 

Par ailleurs, dans l'exemple decrit ci-dessus, il a ete fait reference a une 
application de type annuaire, mais le procede de l'invention est egalement utilise dans 
des application de type conferences ou publications. 

D'une facon generale, la description ci-dessus ne doit pas etre comprise 

30 comme reduisant en quoi que ce soit la portee de la presente invention telle que 
revendiquee dans les revendications annexees. 
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REVENDICATIONS 

L Procede de stockage d'objets informationnels ou objets (6), dans vine base de 
donnees relationnelle (2) stockee dans un ordinateur serveur (1), ladite base 
de donnees relationnelle (2) etant constituee de tables, chaque table etant 
5 constituee d'un tableau d'ensembles de donnees simples, lesdits ensembles 

ayant la meme structure de donnees dans une meme table, chaque donnee 
simple d f une table etant designee par un identifiant unique dans ladite table, 
un objet (6) etant constitue d'une ou plusieurs donnees simples pouvant etre 
stockees dans une table de ladite base de donnees (2), et/ou d f un ou plusieurs 

10 objets emboites dans ledit objet, ledit emboitement pouvant Stre realise sur 

un nombre quelconque de niveaux pour realiser im objet (6), un objet 
emboite ou une donnee simple etant dit localement en nombre fixe s f il ou 
elle apparait exactement une fois dans Tobjet le ou la contenant 
immediatement et etant dit localement en nombre variable dans le cas 

1 5 contraire, une donnee simple apparaissant a un niveau quelconque dudit 

objet (6) etant dite globalement en nombre fixe si elle est localement en 
nombre fixe et si tous les objets la contenant sont localement en nombre 
fixe, une donnee simple apparaissant a un niveau quelconque dudit objet (6) 
etant dite globalement en nombre variable si elle est localement en nombre 

20 variable ou si Tun quelconque des objets la contenant est localement en 

nombre variable, lesdites donnees globalement en nombre fixe d'un objet a 
stocker (6) etant stockees dans un ensemble de donnees principal (31) stocke 
dans une table principale (3) de ladite base de donnees (2), lesdites donnees 
simples globalement en nombre variable dudit objet a stocker (6) etant 

25 stockees dans une ou une ou plusieurs tables annexes (4, 5, 7) de ladite base 

de donnees (2), caracterise par le fait que, lorsqu ! elles existent, les donnees 
simples globalement en nombre variable desdits objets (6) sont stockees 
dans une unique table annexe (7) de ladite base de donnees, le procede 
creant un ou plusieurs ensembles de donnees annexes (71) pour stocker 

30 lesdites donnees simples globalement en nombre variable dans ladite unique 

table annexe (7). 

2. Procede selon la revendication 1, dans lequel chacun desdits un ou plusieurs 
ensembles annexes (71) eventuellement stockes dans ladite unique table 
annexe (7) comporte en outre un ensemble (72) d'indicateurs booleens, 
35 chaque indicateur booleen etant associe a une donnee particuliere desdites 

donnees simples globalement en nombre variable stockees dans ledit 
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ensemble annexe (71), ledit indicateur booleen indiquant si ladite donnee 
simple globalement en nombre variable associee est definie ou non dans 
ledit ensemble annexe (71). 

3. Procede selon la revendication 2, dans lequel certains desdits indicateurs 
5 booleens dudit ensemble (72) d'indicateurs booleens sont communs a 

plusieurs donnees simples globalement en nombre variable lorsque lesdites 
donnees simples sont localement en nombre fixe dans un meme objet les 
contenant immediatement. 

4. Procede selon Tune quelconque des revendications precedentes, dans lequel 
1 o ledit ensemble principal (31) associe au dit objet (6) a stocker comporte une 

donnee (11) permettant d f identifier de fa9on unique ledit ensemble principal 
(31) dans ladite table principale (3). 

5. Procede selon la revendication 4, dans lequel ladite donnee unique (11) est 
unique dans ledit ordinateur serveur (1). 

15 6. Procede selon Tune des revendications 4 ou 5, dans lequel ladite donnee 

unique (11) stockee dans ledit ensemble principal (31) associe au dit objet 
(6) a stocker est en outre stockee dans chacun des ensembles annexes (71) 
associes au dit objet (6) a stocker, pour permettre la mise en relation dudit 
ensemble principal (3) et du ou desdits ensembles annexes (71) eventuels 

20 associes au dit objet (6) a stocker. 

7. Procede selon Tune quelconque des revendications 4 a 6, dans lequel ladite 
donnee unique (1 1) est constituee du nom logique de l'ordinateur serveur (1) 
sur ledit reseau (60), du numero de table de ladite table principale (3) dans 
ladite base de donnees (2) et du numero d'ensemble de donnees dudit 

25 ensemble principal (3 1 ) dans ladite table principale (3), ledit nom logique de 

l'ordinateur serveur (1) etant unique sur ledit reseau <60), ladite base de 
donnees (2) etant unique sur ledit ordinateur serveur (1), ledit numero de 
table de ladite table principale (3) etant unique dans ladite base de donnees 
(2) et ledit numero d'ensemble de donnees dudit ensemble principal (31) 

30 etant unique dans ladite table principale (3). 

8. Procede selon Tune quelconque des revendications precedentes, dans lequel 
deux objets (6) a stocker sont dits de meme type s'ils sont constitues de 
donnees simples et d'objet emboites de meme type, deux objets (6) de meme 
type ayant en commun un meme identifiant et les donnees simples et/ou les 

35 objets emboites se correspondant a un niveau quelconque desdits objets (6) 
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de meme type ayant en commun un meme identifiant, unique dans Pobjet les 
contenant immediatement. 

9. Procede selon la revendication 8, dans lequel le procede cree un identifiant 
global pour tous les objets (6) de meme type et pour toutes les donnees 

5 simples se correspondant a un niveau quelconque desdits objets (6) de 

meme type, ledit identifiant global etant ledit identifiant commun pour 
lesdits objets de meme type, et ledit identifiant global etant obtenu, pour 
chacune desdites donnees simples se correspondant, par la concatenation des 
identifiants, dans les objets les contenant immediatement, de tous les objets 
1 0 contenant ladite donnee simple, et de Tidentifiant de ladite donnee simple 

dans Tobjet la contenant immediatement. 

10. Procede selon la revendication 9, dans lequel le nombre de caracteres de 
ridcntifiant global est tronque au nombre de caracteres permis par ladite 
base de donnees (2) pour Tidentifiant d'une donnee stockee dans une table de 

15 ladite base de donnees (2). 

11. Procede selon la revendication 10, dans lequel une ambiguite pouvant 
apparaitre du fait de ladite troncature est resolue en effectuant les etapes 
consistant a : 

remplacer le dernier caractere alphabetique de l'identifiant global par le 
20 chiffre zero, ainsi que les eventuels chiffres le suivant ; 

augmenter d'une unite le nombre constitue par Tensemble des chiffres 

apparaissant a la fin dudit identifiant global jusqu'a ce que Tambiguite 

disparaisse ou que les chiffres a la fin dudit identifiant global soient 

entierement constitues de chiffres neuf ; 
25 - repeter les etapes precedentes depuis le debut lorsque les chiffres 

apparaissant a la fin dudit identifiant global sont entierement constitues 

de chiffres neuf a Tissue de Tetape precedente. 

12. Procede selon Tun quelconques des revendications precedentes, dans lequel 
les objets (6) stockes dans la base de donnees (2) sont re9us ou transmis par 

30 Tordinateur serveur (1) via un reseau informatique (60) de type Internet. 

13. Procede selon Tune des quelconques des revendications precedentes, dans 
lequel les donnees simples constituant lesdits objets (6) stockes dans ladite 
base de donnees (2) sorit de type texte. 

14. Procede selon la revendication 13, dans lequel lesdites donnees simples de 
35 type texte sont des donnees ecrites en langage XML. 
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15. Procede selon la revendication 14, dans lequel lesdites donnees ecrites en 
langage XML sont conformes a une description (92) de type XML Schema. 

16. Procede selon la revendication 15, dans lequel un ensemble de donnees (95) 
au format XML est obtenu par une traduction automatique de ladite 

5 description (92), ledit ensemble de donnees (95) et un ensemble de donnees 

complementaire (96) etant a leur tour traduits automatiquement en langage 
SQL pour definir et gerer la structure de la base de donnees (2), et pour 
controler les echanges de donnees avec ladite base de donnees (2). 

17. Procede selon Tune quelconque des revendications 14 a 16, dans lequel une 
] o partie des donnees simples des objets (6) re9us par ledit reseau (60) de type 

Internet est supprimee a l'aide d'un patron, ou modele, d'objet (61) ecrit en 
langage XML, pour interdire la modification desdites donnees simples via 
ledit reseau (60). 

18. Procede selon Tune quelconque des revendications 14 a 17, dans lequel une 
1 5 partie des donnees simples des objets transmis via ledit reseau est supprimee 

a l'aide d'un patron d'objet (61) ecrit en langage XML pour limiter la 
transmission sur ledit reseau (60) a certaines donnees simples desdits objets 
(6). 

19. Procede selon la revendication 18, dans lequel la suppression detune partie 
20 des donnees simples contenues dans les objets (6) permet en outre 

d'optimiser les requetes a ladite base de donnees (2). 

20. Systeme de stockage d'objets informationnels ou objets (6), dans une base 
de donnees relationnelle (2) stockee par un ordinateur serveur (1), 
caracterise par le fait qu'il met en oeuvre le prodede selon Tune quelconques 

25 des revendications precedentes. 
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